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5) Q Claim(s) is/are allowed. 

6) ^3 Claim(s) 1-27 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 
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10) 13 The drawing(s) filed on 06 September 2000 is/are: a)S accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
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application from the International Bureau (PCT Rule 17.2(a)). 
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a) □ The translation of the foreign language provisional application has been received. 
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reference was included in the first sentence of the specification or in an Application Data Sheet. 37 CFR 1 .78. 
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DETAILED ACTION 



Priority 



1 . Applicant claims priority to U.S. patent application 08/585,628 filed 01/16/1996 titled 
"Voice Internet Transmission System" (see WO 97/29581) and U.S. patent application 
08/599,238 filed 02/09/1996 titled "Facsimile Internet Transmission System" (see WO 
97/26753) to C-I-P application 09/655,659 titled "Private IP communications network 
architecture". In summary, the examiner only recognizes priority with respect to claim 25 since 
claim 25 recites subject matter related to a telephone which is found outside of an appcenterlOO 
(see application's figure 1). Examiner's reasoning for why the remainder of the claims is not 
given priority is as follows. 

In general, none of applicant's figures in the parent applications (08/585,628 and 
08/599,238) are found in the child application (09/655,659) such that the examiner considers the 
subject matter found in each of the drawings of the child application new matter. Furthermore, 
applicant in the child application makes no clear distinction on what is new subject matter. In 
general, applicant claims a hybrid VoIP signaling protocol (in relation to H.323 and SIP) called 
MCP. In particular, as shown in figure 1, a communications engine (CE) 50 (i.e., gateway or 
equivalent) uses MCP to communicate with a central arbitration server (CAS) 40 which in-turn 
communicates to a destination communications engine 50 where the communication takes place 
over both a control path and data (i.e., real-time) path. Applicant's parent applications fail to at 
least disclose a central arbitration server (CAS) and furthermore fail to disclose both a control 
path and data (i.e., real-time) path. Thus although applicant claims a fax and voice gateway (i.e., 
communications engine 50), examiner notes that the prior gateways do not function the same and 
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thus are unique and distinct. Furthermore, examiner notes that in fact applicant's parent 
applications teach away from the use of a central arbitration server (e.g., see page 13, lines 1-10 
of WO 97/29581 which is 08/599,238). Thus with respect to figure 1, the examiner has given 
priority to any device that falls outside of the dashed lines showing the appcenter 100 which 
includes a telephone as recited in claim 24. Thus the limitations recited in claims 1-23 and 25-27 
were not given priority. 

Claim Rejections - 35 USC § 112 

2. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

3. Claim 14 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the 
written description requirement. The claim(s) contains subject matter which was not described 
in the specification in such a way as to reasonably convey to one skilled in the relevant art that 
the inventor(s), at the time the application was filed, had possession of the claimed invention. In 
particular, for claim 14 the examiner notes three items of issue with respect to a label as recited 
in the claim. 

For the first item, applicant is silent or deficient on how value-name pairs are 

implemented with respect to the MCP protocol (i.e., labels with respect to the recited claimed 

subject matter). In particular, applicant discloses the following on page 21, lines 7-15: 

The IMCP-RTis a lower overhead protocol designed to also carry information 
about the data it carries. If more than one frame is destined for the same destination, the 
IMCP layer will combine all the frames into a single UDP packet (or multiple packets in 
the case of a large number of connection packets.) This can reduce the network 
bandwidth up to 40% and more in a real world environment The frames within the 
packet are also labeled with their content data type, such as voice. DTMF tones. 
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facsimile, background noiseMsital data, modem, silence, or other data type. This 
labeling allows the end device to process the frames without further analysis. A 
conferencing server would ignore packets labeled as silence or background noise since 
there would be no need to add this data to a conference call. 

The control portion of the IMCP is a text-based protocol. All the data is sent as a 
value-name pair. This allows for extensible messages that need not carry all the optional 
fields if they are not used. It also allows for devices using different versions of the 
protocol to use the same packets if the higher version device has backward compatibility. 
Higher-level protocols, such as the call control, are implemented as a set of IMCP 
messages. 

Thus applicant discloses that the IMCP method uses a text-based protocol for the control portion. 

Notability absent from the above passage is how the real-time/data portion is implemented which 

is also addressed later in the rejection as the second issue. In particular, all the values are 

transmitted as a value-name pair. Applicant clarified the context of the value-name pair in the 

preceding pages by disclosing the differences between IMCP and SIP at page 18, line 14 - page 

19, line 17 as shown below. 

"In addition to supporting the most important features required by high quality 
telephony call setup, IMCP outperforms the basic requirements in some important 
aspects. For example, IMCP features fast setup time where multiple events are handled 
in the same message. Fast setup provides call setup times equivalent to or better than 
PSTN setup time. The faster call setup is due in part to the fact that VoIP network 
signaling is only performed at the end points and not at every switch along the call path. 
Additionally, the complexity required from an IMCP terminal is minimal. Low complexity 
minimizes the load requirements to process call setup, thereby allowing IMCP devices to 
be simple embedded devices. In this respect IMCP is similar to the SIP protocol, in that 
IMCP messages are text based and do not require special compilers or field allocation as 
in H.323 with ASN.L While the text-based approach does require higher bandwidth, the 
complexity reduction during call setup outweighs this tradeoff. In fact, the overall higher 
bandwidth generates an insignificant amount of data when compared to the real-time 
payload data being transmitted in the overall scheme of the architecture. Another 
advantage of IMCP is the broad range of PSTN support available. As the basic IMCP 
call setup procedure is compliant with the Q.931 state machines, the interface to 
traditional PSTN networks is relatively straightforward. This also improves the 
integration time of new servers using off the shelf hardware and software components 
into the network. Yet another advantage of the text based IMCP is the inherent support 
for new message types. As the IMCP message format is text based, there are no coding 
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limits and compatibility issues when new messages or message types are added, 
additional text fields are easily ignored. Finally, IMCP is the base protocol so there are 
no lower layer protocols required. IMCP does not specify a lower layer protocol. Unlike 
SIP, which runs on top of the HTTP protocol or the H.323 that requires an ASN.l 
compiler and SSL. IMCP is simply integrated on top of the well-known TCP/IP and 
UDP/IP protocols. This feature allows IMCP quick and efficient integration to any 
device using a standard C compiler. Note that the IMCP call setup can be generalized to 
any IMCP device f whether it is a PSTN gateway (CE) or a store and forward resource. It 
can also be generalized to carry any type of media. " 

At first issue is how the value-name is implemented with respect to IMCP. In particular, 

applicant recites that the values-name pairs are implemented like SIP since they are text-based 

but they are not implemented like SIP since they do not run on top of the HTTP protocol (i.e., 

they do not use a URL value-name pair such as that disclosed in RFC 2806). Examiner notes the 

above statement to be contradictory and has search applicant's specification for further 

clarification on the deficiency. The examiner has not found further clarification on how such 

value-name pairs are implemented (i.e., applicant's specification does not solve the above-cited 

deficiency). For example, with respect to the fields recited in the claims, applicant discloses the 

following at page 21, lines 7-16: 

"The IMCP-RT is a lower oyerhead protocol designed to also carry information 
about the data it carries. If more than one frame is destined for the same destination, the 
IMCP layer will combine all the frames into a single UDP packet (or multiple packets in 
the case of a large number of connection packets.) This can reduce the network 
bandwidth up to 40% and more in a real world environment. The frames within the 
packet are also labeled with their content data type, such as voice. DTMF tones, 
facsimile, background noise, digital data, modem, silence, or other data type . This 
labeling allows the end device to process the frames without further analysis A 
conferencing server would ignore packets labeled as silence or background noise since 
there would be no need to add this data to a conference call " 

Absent from the paragraph above is how the packets are labeled. In particular, how the packets 
are integrated without using a lower-layer such as HTTP for a name-value pair . Applicant 



Application/Control Number: 09/655,659 Page 6 

Art Unit: 2663 

discloses a hybrid approach for an IMCP protocol that incorporates properties of SIP and H.323 

where applicant merely recites that applicant's invention overcomes said deficiencies but does 

not disclose how the invention is implemented to overcome said deficiencies. Thus applicant is 

not in possession of the claimed subject matter since if there are no lower layer protocols to 

make an IMCP protocol, it is unclear how one skilled in the art would implement applicant's 

claimed invention using a value-named pair. For the purpose of making the 102/103 rejection(s) 

below, the examiner assumes that it would have been obvious to one skilled in the art to 

implement the value-name pairs as URL value-name pairs. In particular, examiner takes the 

same implied reasoning provided by applicant in applicant's specification (i.e., since applicant 

relies on prior implementations to overcome the deficiencies) by assuming that it would have 

been obvious to combine certain attributes of H.323 with other attributes of SIP since both 

protocols are well known in the art prior to applicant's invention to make the IMCP protocol 

At second issue, is how a data path label is transported using the IMCP protocol as 

recited with respect to claim 14. Applicant's invention discloses the following: 

"The IMCP protocol has two primary data activities: real time and control The 
real time portion or IMCP-data transfer is designed to carry the payload or the media 
packets between two IMCP devices after a successful call setup. This would be, for 
example, voice, fax, modem, silence, background noise, video, or other data types in the 
future. The control portion of IMCP-call setup is designed to carry network events 
(DTMF and other tones), applications, data, or private data and is illustrated in Figure 
2a. IMCP-Call setup also defines the messages required to setup a call between two 
IMCP endpoints. The relationship of the real time portion to the control portion is 
illustrated in Figure 2b. " 

Thus applicant discloses two types of protocols: real-time (i.e., data) and control. Applicant 
discloses that control information (i.e., the first type) is sent using value-name pairs (see above). 
Applicant is silent or deficient to how real-time (i.e., data information) is sent other then 
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disclosing that labels are used. Thus it is unclear how the second type of information is sent 
using IMCP. Examiner notes that the second issue is related to the first issue in that this is 
another example of how applicant is not in possession of the claimed invention. For the purpose 
of making the 102/103 rejections the examiner assumes that it would have been obvious to use 
value-name pairs for both real-time (i.e., data) and control protocols. 

At third issue is how silence/background noises are represented as a label. Support for 
silence/background noises is found at page 18, lines 6-13; page 21, lines 7-16; and page 24, line 
18 to page 25, line 17 of applicant's specification. In particular, these sections disclose that a 
packet is labeled in general but does not disclose how a packet is labeled with respect to 
silence/background noises. Thus this is yet another specific example of how applicant is not in 
possession of the claimed invention since it is unclear from applicant's specification on how a 
packet is labeled for silence/background noises in initiating a data path. For the purpose of 
making the 102/103 rejection the examiner assumes a reasonable but broad interpretation of 
"silence/background" noises since these terms are not defined in applicant's specification. 

4. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

5. Claims 1-14 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. In particular, the term "service request" as found at claim 1, lines 7 and 9 does not 
appear in applicant's specification. Thus applicant does not clearly and distinctly define the term 
or its logical equivalents. The examiner has made an assumption in order to overcome the 1 12- 
second paragraph for the purpose of making the 102/103 rejections found below. In particular, 
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the examiner assumes a reasonable but broad interpretation of "service request" to include, inter 
alia, a "LockLine" signal (e.g., see applicant's specification on page 30, line 15). As claims 2- 
14 depend on the independent claim(s), these claims also stand rejected. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 1 02 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

7. Claims 1-4, 6, 9-13, 15, 16, and 21-23 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over "Supplementary Services in the H.323 IP Telephony Network" to Korpi et al 
("Korpi") in view of "H.323: The Multimedia Communications Standard for Local Area 
Networks" to Thorn. 

As to claim 1, Korpi discloses a control path connection on a network layer 
between individual components attached to the dispersed networks (e.g., applicant's CE 
50) and at least one central arbitration server (e.g., applicant's CAS 40) as shown in 
figure 1 on page 119. In particular, a fax/voice gateway is an example of an individual 
component (i.e., applicant's CE 50) and Gatekeeper Y/Router is an example of a central 
arbitration server (i.e., in reference to applicant's specification on page 17, lines 1-2). In 
addition, a step of initiating a data path connection between the individual components 
designated by the service request is also shown in figure 1. Also shown in the figure is a 
further step of receiving a "service request" using a reasonable but broad interpretation of 
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"service request". In addition, as H.323 runs on top of IP examiner notes IP as a network 
layer. 

Korpi is silent or deficient to the further limitation of the step initiating a service 
level layer to supply the requested service. 

Thorn teaches the above-mentioned further limitation in figure 4 on page 55. 

Examiner notes that it would have been obvious to one skilled in the art prior to 
applicant's invention to include the further limitation of the step initiating a service level 
layer to supply the requested service. In particular, the Korpi reference would be 
modified to disclose initiating a service layer request based on the gatekeeper as shown in 
figure 4. The suggestion or motivation for doing so would have been obvious since both 
reference disclose setting up a call signal in general, and for H.323 in particular. 

As to claim 2, see e.g., at least page 118 left-hand column of Korpi. 

As to claim 3, see e.g., at least page 118 left-hand column with respect to 
gatekeeper of Korpi. 

As to claim 4, see e.g., page 124, right-hand column. 

As to claim 6, see e.g., figure 4 on page 55 of Thorn. 

As to claims 9-11, see e.g., figure 4 on page 55 of Thorn. 

As to claim 12, see e.g., figure 5 on page 55 of Thorn. 

As to claim 13, see e.g., figure 5 on page 55 of Thorn and left-hand column of 
page 119 of Korpi. 

As to claim 15, see similar rejection for claim 1. 

As to claim 16, see e.g., figure 1 on page 1 19 of Korpi. 
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As to claim 21, see e.g., figure 4 on page 55 of Thorn. 

As to claim 22, see e.g., figure 1 on page 1 19 of Korpi. 

As to claim 23, see e.g., figure 4 on page 55 of Thorn. 
8. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over "Supplementary 
Services in the H.323 IP Telephony Network" to Korpi et al ("Korpi") in view of "H.323: The 
Multimedia Communications Standard for Local Area Networks" to Thorn and in further view of 
U.S. Patent No. 6,529,499 Bl to Doshi et al ("Doshi") and U.S. Patent No. 6,504,838 Bl to 
Kwan. 

As to claim 5, for types of data see e.g., page 52, left-hand column of Thorn; and 
page 118, left-hand column of Korpi. Korpi and Thorn are silent to the further limitation 
of modem data and silence^ackground noises. Examiner notes that it would have been 
obvious to one skilled in the art prior to applicant's invention to include modem data and 
silence^ackground noises. In particular, one skilled in the art would be motivated to 
include modem data and silence/background noises as part of transporting voice in 
general since voice contains periods of silence and background noises, and modem data is 
transported over a voice (PSTN) link. (Examiner notes applicant only claims and 
supports that such information is possible to transport on a data path.) As such, Doshi 
cures the above-cited deficiency by disclosing that it is possible to transport 
silence/background information over an H.323/SIP network (e.g., see column 3, lines 1- 
42). As such, Kwan cures the above-cited deficiency by disclosing that it is possible to 
transport modem information over an H.323 network (e.g., figure 5; column 10, lines 5- 
24). 
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9. Claims 7 and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
"Supplementary Services in the H.323 IP Telephony Network" to Korpi et al ("Korpi") in view 
of "H.323: The Multimedia Communications Standard for Local Area Networks" to Thorn and in 
further view of U.S. Patent No. 6,519,249 Bl to Bennefeld et al <?Bennefel<F\ 

As to claim 7, Korpi and Thorn are silent to the further limitation of recoding and 
monitoring the call control messages (i.e., billing information). Although Korpi does 
disclose that the gatekeeper supports accounting (e.g., see left-hand column on page 118), 
Korpi may be silent to monitoring and storing the call control messages. Examiner notes 
that it would have been obvious to one skilled in the art prior to applicant's invention to 
include recoding and monitoring the call control messages. In particular, one skilled in 
the art would be motivated to record and monitor call detail records for the purpose of 
generating revenue for data on a network. As such, Bennefeld cures the above-cited 
deficiency by disclosing recording and monitoring billing information. In particular, 
Bennefeld discloses monitoring and recording with respect to a gatekeeper on an H.323 
network (e.g., see at least column 1, lines 60-67). 

As to claim 8, Korpi and Thorn are silent to the further limitation of optimizing 
routing resources using at least, least cost routing, failure bypass, load balancing, and 
class or service. In particular, Thorn teaches that QoS is generally not supported in H.323 
(e.g., see page 56, left-hand column). Examiner notes that it would have been obvious to 
one skilled in the art prior to applicant's invention to optimize routing resources using at 
least, least cost routing, failure bypass, load balancing, and class or service. In particular, 
one skilled in the art would be motivated to optimize a route based on the dynamic 
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environment of a network. As such, Bennefeld cures the above-cited deficiency by 
disclosing that routes can be optimized by at least load balancing for a dynamic network 
(e.g., see at least column 1, lines 60-67; column 3, lines 12-26). 
10. Claims 14, 20, 24, 26, and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over "Supplementary Services in the H.323 IP Telephony Network" to Korpi et al ("Korpi") in 
view of "H.323: The Multimedia Communications Standard for Local Area Networks" to Thorn 
and in further view of U.S. Patent Application 2001/0046234 Al to Agrawal et al ("AgrawaF) 
and "RFC 2806 - URLS for Telephone Calls" to Vaha-Sipila. 

As to claim 14 Korpi and Thorn are silent to the further limitation of using a (text) 
label. In particular, since Korpi and Thorn teach using H.323, Korpi and Thorn teach 
using binary encoding instead of a (text) label (e.g., see figure 1 of Agrawal). Examiner 
notes that it would have been obvious to one skilled in the art prior to applicant's 
invention to use labels since labels are supported for a SIP protocol. In particular, one 
would be motivated to use labels to communicate with at least a SIP network since a SIP 
protocol communicates using text labels. As support and motivation, Agrawal discloses 
using labels. In particular, as shown in figure 5 an IWF 100 function is capable of 
operating over both SIP and H.323. Thus both properties of SIP and H.323 are further 
taught by the reference (e.g., the reference teaches using both binary for H.323 and text 
labels for SIP when communicating to a gatekeeper/server). As an additional reference, 
Vaha-Sipila further builds on the concept by disclosing specific labels for a SIP network 
including telephone, fax, and voice information. Thus Vaha-Sipila further teaches the 
limitation of varying a call detail record based in part upon the data type (text) label. 



Application/Control Number: 09/655,659 Page 13 

Art Unit: 2663 

As to claim 20, see similar rejection to claim 14 where examiner notes a 
reasonable but broad interpretation of IMCP to be either SIP or H.323 (i.e., applicant 
does not claim specific attributes of IMCP such as a text label running on top of or at a 
network layer). 

As to claims 24 and 26, see e.g., the combined reasoning for the rejections for 
claims 1 and 14. 

As to claims 27, see figure 1 of KorpL 
11. Claims 17, 18, and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
"Supplementary Services in the H.323 IP Telephony Network" to Korpi et al ("Korpi") in view 
of "H.323: The Multimedia Communications Standard for Local Area Networks" to Thorn and in 
further view of "C6x Solutions for Voice over IP Gateway" to Cassing. 

As to claim 17, Korpi and Thorn are silent to the further limitation using a digital 
signal processor on receiving signals to generate encoded signals at the gateway for a 
control path. In particular, Thorn discloses translating call signaling but is silent or 
deficient to using a DSP (e.g., see page 54, left-hand column). Examiner notes that it 
would have been obvious to one skilled in the art prior to applicant's invention to use a 
digital signal processor on receiving signals to generate encoded signals at the gateway 
for a control path. One skilled in the art would be motivated to use a DSP in the gateway 
for voice compression such as G.723. 1 . Cassing cures the above-cited deficiency by 
disclosing a DSP in a VoIP gateway such as an H.323 gateway (e.g., see page 76 Section 
3.1). Thus Cassing provides support and motivation for using a digital signal processor 
on receiving signals to generate encoded signals at the gateway for a control path. 
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As to claims 18 and 19, see figure 1 of Korpi. 
12. Claim 25 is rejected under 35 U.S.C. 103(a) as being unpatentable over "Supplementary 
Services in the H.323 IP Telephony Network" to Korpi et al ("Korpi") in view of "H.323: The 
Multimedia Communications Standard for Local Area Networks" to Thorn and in further view of 
U.S. Patent Application 2001/0046234 Al to Agrawal et al ("AgrawaF'), "RFC 2806 - URLS 
for Telephone Calls" to Vaha-Sipila, and U.S. Patent No. 5,471,470A to Sharma et al 
("Sharma"). 

As to claim 25, Korpi, Thorn, Agrawal, and Vaha-Sipila are silent to the further 
limitation of the specific structure of a telephone which includes at least a speaker and a 
microphone. Examiner notes that it would have been obvious to one skilled in the art 
prior to applicant's invention to use a telephone which includes at least a speaker and a 
microphone. In particular, one skilled in the art would be motivated to use a microphone 
to talk into a telephone and use a speaker to listen to an incoming call as is known in the 
art. Sharma provides further support and motivation by disclosing in figure 3 a 
telephone (shown as 20 in figure 1) that has at least a microphone 303 and speaker 304 
(e.g., see column 8). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Derrick W. Ferris whose telephone number is (703) 305-4225. 
The examiner can normally be reached on M-F 9 A.M. - 4:30 P.M. E.S.T. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chau Nguyen can be reached on (703) 308-5340. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is 305-3900. 




Derrick W. Ferris 
Examiner 
Art Unit 2663 




